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Over Transport Layer Security (TLS) 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 

Abstract 
This document describes how to use Transport Layer Security (TLS) to 
secure Common Open Policy Service (COPS) connections over the 


Internet. 


This document also updates RFC 2748 by modifying the contents of the 
Client-Accept message. 
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1. Introduction 


COPS [RFC2748] was designed to distribute clear-text policy 
information from a centralized Policy Decision Point (PDP) to a set 
of Policy Enforcement Points (PEP) in the Internet. COPS provides 
its own security mechanisms to protect the per-hop integrity of the 
deployed policy. However, the use of COPS for sensitive applications 
(e.g., some types of security policy distribution) requires 
additional security measures, such as data confidentiality. This is 
because some organizations find it necessary to hide some or all of 
their security policies, e.g., because policy distribution to devices 
such as mobile platforms can cross domain boundaries. 


TLS [RFC2246] was designed to provide channel-oriented security. TLS 
standardizes SSL and may be used with any connection-oriented 
service. TLS provides mechanisms for both one- and two-way 
authentication, dynamic session keying, and data stream privacy and 
integrity. 


This document describes how to use COPS over TLS. "COPS over TLS" is 
abbreviated COPS/TLS. 


Walker & Kulkarni Standards Track [Page 2] 


RFC 4261 COPS Over TLS December 2005 


Glossary 
COPS - Common Open Policy Service. See [RFC2748]. 
COPS/TCP - A plain-vanilla implementation of COPS. 
COPS/TLS - A secure implementation of COPS using TLS. 


PDP - Policy Decision Point. Also referred to as the Policy Server. 
See [RFC2753]. 


PEP - Policy Enforcement Point. Also referred to as the Policy 
Client. See [RFC2753]. 


Conventions used in this document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. COPS Over TLS 


COPS/TLS is very simple: use COPS over TLS similar to how you would 
use COPS over TCP (COPS/TCP). Apart from a specific procedure used 
to initialize the connection, there is no difference between COPS/TLS 
and COPS/TCP. 


3. Separate Ports versus Upward Negotiation 


There are two ways in which insecure and secure versions of the same 
protocol can be run simultaneously. 


In the first method, the secure version of the protocol is also 
allocated a well-known port. This strategy of having well-known port 
numbers for both, the secure and insecure versions, is known as 
‘Separate Ports’. The clients requiring security can simply connect 
to the well-known secure port. This method is easy to implement, 
with no modifications needed to existing insecure implementations. 
The disadvantage, however, is that it doesn’t scale well, because a 
new port is required for each secure implementation. More problems 
with this approach have been listed in [RFC2595]. 


The second method is known as 'Upward Negotiation’. In this method, 
the secure and insecure versions of the protocol run on the same 
port. The client connects to the server, both discover each others’ 
capabilities, and start security negotiations if desired. This 
method usually requires some changes to the protocol being secured. 
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In view of the many issues with the Separate Ports approach, the 
authors have decided to use the Upward Negotiation method for 
COPS/TLS. 


4. COPS/TLS Objects and Error codes 


This section describes the COPS objects and error codes needed to 
support COPS/TLS. 


4.1. The TLS Message Integrity Object (Integrity-TLS) 


The TLS Integrity object is used by the PDP and the PEP to start the 
TLS negotiation. This object should be included only in the Client- 
Open or Client-Accept messages. It MUST NOT be included in any other 
COPS message. 


0 1 2 3 
Ho Ho +---------- Ho + 
| Length (Octets) | C-Num=16 | C-Type=2 | 
Ho Ho +---------- $ + 
| 11111711 | Flags | 
Ho Ho Ho +---------- + 


Note: //// implies the field is reserved, set to 0, and should 
be ignored on receipt. 


Flags: 16 bits 
0x01 = StartTLS 
This flag indicates that the sender of the message 
wishes to initiate a TLS handshake. 


The Client-Type of any message containing this object MUST be 0. 
Client-Type 0 is used to negotiate COPS connection level security and 


must only be used during the connection establishment phase. Please 
refer to section 4.1 of [RFC2748] for more details. 


4.2. Error Codes 


This section uses the error codes described in section 2.2.8 (Error 
Object) of [RFC2748]. 


Error Code: 13= Unknown COPS Object: 
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Sub-code (octet 2) contains the unknown object’s C-Num, and (octet 3) 
contains unknown object’s C-Type. If the PEP or PDP does not support 
TLS, the C-Num specified MUST be 16 and the C-Type MUST be 2. This 
demonstrates that the TLS version of the Integrity object is not 
known. 


This error code MUST be used by either PEP or PDP to indicate a 
security-related connection closure if it cannot support a TLS 
connection for the COPS protocol. 


If the PDP wishes to negotiate a different security mechanism than 
requested by the PEP in the Client-Open, it MUST send the following 
error code: 


Error Code: 15= Authentication Required 


Where the Sub-code (octet 2) contains the C-Num=16 value for the 
Integrity Object and (octet 3) MUST specify the PDP 
required/preferred Integrity object C-Type. If the server does not 
support any form of COPS-Security, it MUST set the Sub-code (octet 2) 
to 16 and (octet 3) to zero instead, signifying that no type of the 
Integrity object is supported. 


5. COPS/TLS Secure Connection Initiation 
Security negotiation may be initiated by either the PDP or the PEP. 


The PEP can initiate a negotiation via a Client-Open message, while a 
PDP can initiate a negotiation via a Client-Accept message. 


Once the TLS connection is established, all COPS data MUST be sent as 
TLS "application data". 


5.1. PEP Initiated Security Negotiation 


A PEP MAY initiate a TLS security negotiation with a PDP using the 
Client-Open message. To do this, the Client-Open message MUST have a 
Client-Type of 0 and MUST include the Integrity-TLS object. 


Upon receiving the Client-Open message, the PDP SHOULD respond with a 
Client-Accept message containing the Integrity-TLS object. 


Note that in order to carry the Integrity-TLS object, the contents of 
the Client-Accept message defined in section 3.7 of [RFC2748] need 
not change, except that the C-Type of the integrity object contained 
there-in should now be C-Type=2. For Example: 
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<Client-Accept> ::= <Common Header> 
<KA Timer> 
[<ACCT Timer>] 
[<Integrity (C-Num=16, C-Type=2) >] 


Note also that this new format of the Client-Accept message does not 
replace or obsolete the existing Client-Accept message format, which 
can continue to be used for non-secure COPS session negotiations. 


Upon receiving the appropriate Client-Accept message, the PEP SHOULD 
initiate the TLS handshake. 


The message exchange is as follows: 


C: Client-Open (Client-Type = 0, Integrity-TLS) 
S: Client-Accept (Client-Type 0, Integrity-TLS) 
<TLS handshake> 

C/S: <...further messages...> 


In case the PDP does not wish to open a secure connection with the 
PEP, it MUST reply with a Client-Close message and close the 
connection. The Client-Close message MUST include the error code 15= 
Authentication reguired, with the Sub-code (octet 2) set to 16 for 
the Integrity object’s C-Num, and (octet 3) set to the C-Type 
corresponding to the server’s preferred Integrity type, or zero for 
no security. 


A PEP requiring the Integrity-TLS object in a Client-Accept message 
MUST close the connection if the Integrity-TLS object is missing. 
The ensuing Client-Close message MUST include the error code 15= 
Authentication required, with the Sub-code (octet 2) containing the 
required Integrity object’s C-Num=16, and (octet 3) containing the 
required Integrity object’s C-Type=2. 


5.2. PDP Initiated Security Negotiation 


The PEP initially opens a TCP connection with the PDP on the standard 
COPS port and sends a Client-Open message. This Client-Open message 
MUST have a Client-Type of 0. 


The PDP SHOULD then reply with a Client-Accept message. In order to 
signal the PEP to start the TLS handshake, the PDP MUST include the 
Integrity-TLS object in the Client-Accept message. 


Upon receiving the Client-Accept message with the Integrity-TLS 


object, the PEP SHOULD initiate the TLS handshake. If for any reason 
the PEP cannot initiate the handshake, it MUST close the connection. 
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The message exchange is as follows: 


C: Client-Open (Client-Type = 0) 

S: Client-Accept (Client-Type = 0, Integrity-TLS) 
<TLS handshake> 

C/S: <...further messages...> 


After receiving the Client-Accept, the PEP MUST NOT send any messages 
until the TLS handshake is complete. Upon receiving any message from 
the PEP before the TLS handshake starts, the PDP MUST issue a 
Client-Close message with an error code 15= Authentication Reguired. 


A PDP wishing to negotiate security with a PEP having an existing 
non-secure connection MUST send a Client-Close with the error code 
15= Authentication required, with the Sub-code (octet 2) containing 
the required Integrity object’s C-Num=16, and (octet 3) containing 
the required Integrity object’s C-Type=2, and then wait for the PEP 
to reconnect. Upon receiving the Client-Open message, it SHOULD use 
the Client-Accept message to initiate security negotiation. 


6. Connection Closure 


TLS provides facilities to securely close its connections. Reception 
of a valid closure alert assures an implementation that no further 
data will arrive on that connection. The TLS specification requires 
TLS implementations to initiate a closure alert exchange before 
closing a connection. It also permits TLS implementations to close 
connections without waiting to receive closure alerts from the peer, 
provided they send their own first. A connection closed in this way 


is known as an "incomplete close". TLS allows implementations to 
reuse the session in this case, but COPS/TLS makes no use of this 
capability. 


A connection closed without first sending a closure alert is known as 
a "premature close". Note that a premature close does not call into 
question the security of the data already received, but simply 
indicates that subsequent data might have been truncated. Because 
TLS is oblivious to COPS message boundaries, it is necessary to 
examine the COPS data itself (specifically the Message header) to 
determine whether truncation occurred. 


6.1. PEP System Behavior 
PEP implementations MUST treat premature closes as errors and any 
data received as potentially truncated. The COPS protocol allows the 


PEP system to find out whether truncation took place. A PEP system 
detecting an incomplete close SHOULD recover gracefully. 
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PEP systems SHOULD send a closure alert before closing the 
connection. PEPs unprepared to receive any more data MAY choose not 
to wait for the PDP system’s closure alert and simply close the 
connection, thus generating an incomplete close on the PDP side. 


6.2. PDP System Behavior 


COPS permits a PEP to close the connection at any time, and requires 
PDPs to recover gracefully. In particular, PDPs SHOULD be prepared 
to receive an incomplete close from the PEP, since a PEP often shuts 
down for operational reasons unrelated to the transfer of policy 
information between the PEP and PDP. 


Implementation note: The PDP ordinarily expects to be able to 
signal the end of data by closing the connection. However, the 
PEP may have already sent the closure alert and dropped the 
connection. 


PDP systems MUST attempt to initiate an exchange of closure alerts 
with the PEP system before closing the connection. PDP systems MAY 
close the connection after sending the closure alert, thus generating 
an incomplete close on the PEP side. 


7. Endpoint Identification and Access Control 


All PEP implementations of COPS/TLS MUST support an access control 
mechanism to identify authorized PDPs. This requirement provides a 
level of assurance that the policy arriving at the PEP is actually 
valid. PEP deployments SHOULD require the use of this access control 
mechanism for operation of COPS over TLS. When access control is 
enabled, the PEP implementation MUST NOT initiate COPS/TLS 
connections to systems not authorized as PDPs by the access control 
mechanism. 


Similarly, PDP COPS/TLS implementations MUST support an access 
control mechanism permitting them to restrict their services to 
authorized PEP systems only. However, deployments MAY choose not to 
use an access control mechanism at the PDP, as organizations might 
not consider the types of policy being deployed as sensitive, and 
therefore do not need to incur the expense of managing credentials 
for the PEP systems. If access controls are used, however, the PDP 
implementation MUST terminate COPS/TLS connections from unauthorized 
PEP systems and log an error if an auditable logging mechanism is 
present. 


Implementations of COPS/TLS MUST use X.509 v3 certificates conforming 
to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST 
perform certificate verification processing conforming to [RFC3280]. 
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If a subjectAltName extension of type dNSName or iPAddress is present 
in the PDP’s certificate, it MUST be used as the PDP identity. If 
both types are present, dNSName SHOULD be used as the PDP identity. 
If neither type is present, the most specific Common Name field in 
the Subject field of the certificate SHOULD be used. 


Matching is performed using the matching rules specified by 
[RFC3280]. If more than one identity of a given type is present in 
the certificate (e.g., more than one dNSName in the subjectAltName 
certificate extension), a match in any one of the provided identities 
is acceptable. Generally, the COPS system uses the first name for 
matching, except as noted below in the IP address checking 
requirements. 


7.1. PEP Identity 


When PEP systems are not access controlled, the PDP does not need 
external knowledge of what the PEP’s identity ought to be and so 
checks are neither possible nor necessary. In this case, there is no 
requirement for PEP systems to register with a certificate authority, 
and COPS over TLS uses one-way authentication, of the PDP to the PEP. 


When PEP systems are access controlled, PEPs MUST be the subjects of 
end entity certificates [RFC3280]. In this case, COPS over TLS uses 
two-way authentication, and the PDP MUST perform the same identity 
checks for the PEPs as described above for the PDP. 


When access controls are in effect at the PDP, PDP implementations 
MUST have a mechanism to securely acquire the trust anchor for each 
authorized Certification Authority (CA) that issues certificates to 
supported PEPs. 


7.2. PDP Identity 


Generally, COPS/TLS requests are generated by the PEP consulting 
bootstrap policy information that identifies PDPs that the PEP is 
authorized to connect to. This policy provides the PEP with the 
hostname or IP address of the PDP. How this bootstrap policy 
information arrives at the PEP is outside the scope of this document. 
However, all PEP implementations MUST provide a mechanism to securely 
deliver or configure the bootstrap policy. 


All PEP implementations MUST be able to securely acquire the trust 
anchor for each authorized Certification Authority (CA) that issues 
PDP certificates. Also, the PEPs MUST support a mechanism to 
securely acquire an access control list (ACL) or filter identifying 
the set of authorized PDPs associated with each CA. Deployments must 
take care to avoid circular dependencies in accessing trust anchors 
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and ACLs. At a minimum, trust anchors and ACLs may be installed 
manually. 


PEP deployments that participate in multiple domains, such as those 
on mobile platforms, MAY use different CAs and access control lists 
in each domain. 


If the PDP hostname or IP address is available via the bootstrap 
policy, the PEP MUST check it against the PDP’s identity as presented 
in the PDP’s TLS Certificate message. 


In some cases, the bootstrap policy will identify the authorized PDP 
only by an IP address of the PDP system. In this case, the 
subjectAltName MUST be present in the certificate, and it MUST 
include an iPAddress format matching the expected name of the policy 
server. 


If the hostname of the PDP does not match the identity in the 
certificate, a PEP on a user-oriented system MUST either notify the 
user (PEP systems MAY afford the user the opportunity to continue 
with the connection in any case) or terminate the connection with a 
bad certificate error. PEPs on unattended systems MUST log the error 
to an appropriate audit log (if available) and MUST terminate the 
connection with a bad certificate error. Unattended PEP systems MAY 
provide a configuration setting that disables this check, but then 
MUST provide a setting that enables it. 


8. Cipher Suite Requirements 


Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 
suite. All other cipher suites are optional. 


9. Backward Compatibility 
The PEP and PDP SHOULD be backward compatible with peers that have 
not been modified to support COPS/TLS. They SHOULD handle errors 
generated in response to the Integrity-TLS object. 

10. IANA Considerations 
The IANA has added the following C-Num, C-Type combination for the 
Integrity-TLS object to the registry at 


http://www.iana.org/assignments/cops-parameters: 


0x10 0x02 Message Integrity, Integrity-TLS [RFC4261] 
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For Client-Type 0, the IANA has added the following Flags value for 
the Integrity-TLS object: 


0x01 = StartTLS 


Further, for Client-Type 0, the IANA has added the following text for 
Error Sub-Codes: 


Error Code: 15 

Error Sub-Code: 

Octet 2: C-Num of the Integrity object 

Octet 3: C-Type of the supported/preferred Integrity object or 
Zero. 


Error-Code Error-SubCode Description 
Octet 2 Octet 3 


15 16 0 No security 
15 16 2 Integrity-TLS supported/preferred 


Further values for the Flags field and the reserved field can only be 
assigned by IETF Consensus rule, as defined in [RFC2434]. 


11. Security Considerations 


A COPS PDP and PEP MUST check the results of the TLS negotiation to 
see whether an acceptable degree of authentication and privacy have 


been achieved. If the negotiation has resulted in unacceptable 
algorithms or key lengths, either side MAY choose to terminate the 
connection. 


A man-in-the-middle attack can be launched by deleting the 
Integrity-TLS object or altering the Client-Open or Client-Accept 
messages. If security is required, the PEP and PDP bootstrap policy 
must specify this, and PEP and PDP implementations should reject 
Client-Open or Client-Accept messages that fail to include an 
Integrity-TLS object. 
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